home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / 3rdparty / lansto.txt < prev    next >
Text File  |  1989-10-25  |  7KB  |  167 lines
  1. ABSTRACT
  2.  
  3. This statement defines how NetWare features like HotFix and
  4. read-after-write verification behave in general, the extent
  5. of a VADD's role in these features, and how the LANStor ESDI
  6. and SCSI VADDs, in particular, implement these features.
  7.  
  8. Included are some comments on DGroup memory-space usage and
  9. the Adaptec 2322b ESDI controller.
  10.  
  11. The word "verification" will be used instead of the longer
  12. phrase "read-after-write verification".
  13.  
  14.  
  15.  
  16. HOTFIX
  17.  
  18. If a VADD runs into a problem, it notifies NetWare and
  19. describes the problem as either a controller error or a
  20. media error.
  21.  
  22. For a controller error, NetWare will retry the operation
  23. several times before shutting down the drive and any other
  24. drives that are participating on the same channel.  HotFix
  25. is not invoked because NetWare assumes that if the
  26. controller is failing, reads and writes performed by HotFix
  27. would fail as well.
  28.  
  29. The HotFix feature is invoked when a VADD reports a media
  30. error;  the controller is working, but for some reason the
  31. data could not be stored or retrieved.  Write operations are
  32. handled simply; a new block (8 512-byte sectors) from the
  33. redirection pool replaces the bad block.  To HotFix a failed
  34. read operation, NetWare recovers as much of the 8-sector
  35. block as possible by doing single-sector reads.  Any missing
  36. data is taken from the mirror drive, if it is available.
  37.  
  38. Usually media errors are detected by the drive's controller.
  39. The VADD consults the controller and, in turn, notifies
  40. NetWare.
  41.  
  42.  
  43. READ-AFTER-WRITE VERIFICATION
  44.  
  45. Theory...
  46.  
  47. The verification feature supplements the fault-tolerent
  48. nature of NetWare.  Each time data is written, it is read
  49. back and verified for accuracy.  If the verification fails,
  50. NetWare is notified and the HotFix feature is invoked
  51. (because the VADD reports the failure as a media error).
  52.  
  53. The intent of this feature is to guarantee that data can be
  54. moved reliably from server memory to the disk-system and
  55. recorded properly.  Two aspects of the disk-system are
  56. checked by this feature; media reliability and
  57. communications (cable) integrity.
  58.  
  59. Sometimes an area of a disk's medium can be written
  60. successfully, yet fail when read at a later time.  By
  61. reading and comparing the data after writing, "soft" errors
  62. of this type can be reduced.  Some disk-system hardware can
  63. perform this function by themselves, independent of a VADD,
  64. O/S or anything else.
  65.  
  66. The cables used in a disk-system are no less important than
  67. the disk drives themselves.  To check their reliability,
  68. data must make a complete circuit from server memory to the
  69. disk-system and back again.  It is crucial that data be
  70. brought back into server memory so it can be compared to the
  71. original.  It is for this reason that disk-system hardware
  72. that perform verification themselves only do half the job
  73. unless the data is somehow brought back into server memory.
  74.  
  75.  
  76. Reality...
  77.  
  78. The higher-quality disk-systems can be counted upon to
  79. either record data properly or provide notification if they
  80. cannot.  Any "soft" errors are usually defeated with an
  81. arsenal of ECC-recovery, retries with skew adjustments and
  82. relocation of bad sectors; all handled automatically by the
  83. disk-system hardware.
  84.  
  85. Communications problems with the cables are usually dealt
  86. with when a new server is installed.  It either works or it
  87. doesn't.  Maybe the cable and controller are too close to
  88. some noisy circuit board or there is a short in the cable or
  89. something like that.  But for the most part, once good
  90. communication is established with the disk-system, it will
  91. remain that way unless the server is moved or outfitted with
  92. different boards.
  93.  
  94. So, depending on your comfort-level, the verification
  95. feature is either burdensome overhead or a degree of extra
  96. insurance in case of intermittent noise problems.
  97.  
  98.  
  99. LANStor READ-AFTER-WRITE VERIFICATION
  100.  
  101. With the introduction of NetWare 2.1x, the O/S no longer
  102. performed the verification automatically.  It became the
  103. responsibility of the VADD to do the verification.  Novell
  104. directed all VADD implementors to include this feature, and
  105. no exceptions were permitted.  The Novell literature does
  106. state that the O/S performs the verification.  Such a
  107. statement is not inaccurate if the writer viewed VADDs and
  108. LAN drivers as part of the O/S.
  109.  
  110. The first LANStor VADDs always did verification, which
  111. involves an extra read following a write.  We later made it
  112. an option because other vendors had excluded this feature
  113. from the very start and we simply didn't perform as well
  114. when compared to them in benchmarks.
  115.  
  116. If you choose to use the verification feature, LANStor will,
  117. during its initialization, reserve one 4096-byte buffer for
  118. each NetWare channel upon which the VADD is loaded.
  119.  
  120.  
  121. LANStor AND DGROUP USAGE
  122.  
  123. The DGroup data area in NetWare is a 64k chunk of memory
  124. somewhere in the file server.  The O/S, LAN drivers, VADDs
  125. and VAPs and the machine stack all share this region.  All
  126. third-party implementors were advised by Novell to curtail
  127. their use of the DGroup area, for DGroup is practically all
  128. used up even before one starts linking in third-party
  129. software.  It is for this reason that all LANStor VADDs use
  130. only about 10 bytes of the DGroup area.
  131.  
  132. LANStor does require memory, but it doesn't take it from
  133. DGroup.  Instead, LANStor dynamically asks NetWare for the
  134. memory that it needs.  The memory is in the form of segments
  135. that are privately owned by LANStor; there are no conflicts
  136. with any other process.
  137.  
  138. A concern that we had early on was the machine stack.  It is
  139. located in DGroup and we were told it is pretty small to
  140. begin with.  It gets reduced in size as third-party software
  141. is linked with NetWare.  All VADDs that we have seen run
  142. with interrupts disabled.  These VADDs can easily control
  143. their stack usage, reducing the chance for a stack overflow.
  144.  
  145. LANStor, on the other hand, runs with interrupts enabled.
  146. We do this so that LAN boards, printers, and other VADDs can
  147. do their thing while we do ours.  Overall system throughput
  148. is increased, along with the risk of stack overflows, since
  149. nested interrupts can occur.  LANStor avoids this by
  150. switching to its own local (and larger) stack whenever it
  151. gets control.
  152.  
  153.  
  154. ADAPTEC 2322B ESDI CONTROLLER
  155.  
  156. This controller lacks the ability to perform the read-after-
  157. write verification function.  It does have a read-ahead
  158. feature, which is a different thing altogether.  The read-
  159. ahead function is simply used to optimize potential
  160. sequential reads.
  161.  
  162. There appears to be a problem with the read-ahead feature,
  163. though this is not verified.  This is why Storage Dimensions
  164. suggests that read-ahead be disabled when using this
  165. controller.
  166.  
  167.  d